Atty. Dkt. No. 200310588-1 



REMARKS 

Applicants respectfully request reconsideration of the present application in view of 
the foregoing amendments and the reasons that follow. Claim 5 has been corrected to end 
with a period, as required by the examiner. A typographical error in Claim 17 has been 
corrected. Applicants respectfully submit that no new matter has been added to the claims by 
way of these amendments. As such, the claim amendments do not necessitate a new search 
by the Examiner. Claims 1-20 are now pending in the application. 

A. Rejections under 35 U.S.C. § 102(e) 

In Section 3 of the Office Action, Claims 1 and 4-8 are rejected under 35 U.S.C. 
§ 102(e) as being anticipated by U.S. Patent Application Publication No. 2003/0149756 
( Grieve) . Applicants respectfully traverse the rejection. 

Grieve does not anticipate Applicants' claimed invention. Simply stated, it does not 
teach each and every limitation required by the pending claims. 

1. Claim 1 

Claim 1 requires: 

obtaining performance metrics for the computer system before 
and after configuration changes implemented in the computer 
system; and 

assessing effectiveness of the computer configuration changes 
based on the obtained performance metrics. 

Grieve does not teach or suggest these limitations. 

In T[ 5 of the Office Action, the Examiner contends that the Grieve abstract and 
Grieve T[ 0033 teach obtaining performance metrics. Applicants respectfully disagree. The 
Grieve abstract teaches methods and systems comprising: (1) "comparing a first 
configuration file representing a . . . configuration at a point in time with a second 
configuration file representing a . . . configuration at an earlier point in time; and indicating 
when a difference exists," Grieve (abstract); and (2) "identifying [configuration] differences 
to an operator," Grieve (abstract). Similarly, Grieve ^ 0033 describes an agent that 
"conduces] inquiries, return[s] configuration information, compares] old and new 
configurations, download[s] and upload[s] device firmware, direct[s] the storage of 
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configuration files . . . and direct[s] updates to the configuration history database." These 
portions of Grieve teach a method of keeping track of configuration changes only. They 
nowhere so much as mention performance metrics, nor suggest that these be recorded also. 
Indeed, Grieve lists a number of databases that might be maintained — a configuration history 
database, a device information database, and a schedules database — but makes no mention of 
a database for obtaining performance metrics or storing them once obtained. See 
Grieve Tf0032. Additionally, although Grieve provides a detailed schema for one such 
database (lff{ Oil 8-0147), that schema does not contain a single field for obtaining 
performance metrics or storing them once obtained. Thus, the cited references do not teach or 
suggest obtaining performance metrics for the computer system as required by Claim 1 — 
before and after configuration changes or otherwise. 

In ^1 5 of the Office Action, the Examiner also cites to Grieve ffll 01 16-0162 as 
teaching a method of assessing effectiveness of the configuration changes based on the 
obtained performance metrics. Applicants again respectfully disagree. These paragraphs in 
Grieve constitute a section entitled "The Configuration History Database and Database 
Manager" (emphasis added). As the title suggests, these paragraphs describe the organization 
of a database for storing configuration histories and an interface for updating that database 
when configurations change. They teach a method of storing configuration changes, but not 
of assessing their effectiveness. For example, they do suggest a method for recovering from a 
configuration change that leads to network failure, but not one for using the fact of that 
network failure as evidence that similar configuration changes should not be applied in future. 
Thus, they do not teach or suggest assessing effectiveness of the computer configuration 
changes, and, in particular, do not suggest doing so on based on the obtained performance 
metrics, as required by Claim 1 . 

2. Claims 4-8 

Claim 4 requires: 

removing computer configuration changes not resulting in 
performance improvements from future recommendation sets. 

In H 6 of the office action, the Examiner contends that Grieve 1fl! 0026, 0045, 0049, 
0072, 0080, 0082, 0098, 0114 and 0151 disclose this feature. Applicants respectfully 
disagree. Grieve \ 0026 summarizes the "new paradigm" of the Grieve invention as one that 
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"provid[es] to the operator a view of the history of configurations of network devices that 
help the operator understand the evolutionary steps that produce working and non-working 
networks" (emphasis added). The other cited paragraphs describe tools that make it easier to 
interact with this history and manually change device configurations: ff 0045 and 0049 
disclose tools to manually remove devices from the network and from groups therein; f 0072 
discloses a tool for manually designating firmware images to be added or removed; f 0080 
discloses a tool for manually removing configuration files; f 0082 discloses a tool for 
manually modifying a queue of scheduled operations; ff 0098 and 0114 disclose tools to add 
or remove components that report on configuration changes; and f 0151 discloses a tool that 
informs the user when the physical make up of the network changes. The cited paragraphs 
thus disclose a method to show the user a history of configuration changes and to allow the 
user to interact with them. They do not disclose or even suggest a way to make 
recommendations to the user about the value of different configuration changes. Also, they 
do not suggest maintaining knowledge bases or other recommendation sets to guide such 
recommendations. Also, they do not suggest maintaining performance information to help 
dynamically update such recommendation sets. Thus, they do not suggest removing computer 
configuration changes not resulting in performance improvements from future 
recommendation sets, as required by Claim 4. 

Claim 5 requires: 

summarizing recommended actions identified for a computer 
user, configuration changes implemented, and the resulting 
change in performance. 

In f 7 of the office action, the Examiner contends that Grieve schedule summary 205 
and ff 0042 and 0083 disclose this feature. Applicants respectfully disagree. The cited 
material describes two summary tools: a summary of scheduled events (schedule 
summary 205, f 0042) and a summary of actions taken by the user against a device (f 0083). 
The schedule summary is a list of the events that the user has specified should be run at 
scheduled times. The change history shows "a global view of the configuration save/restore, 
firmware download, survey, and device reset activity" (f 0083). Thus, both these tools 
summarize actions that the user has taken in the past. The cited references do not teach or 
even suggest summarizing recommended actions identified for a computer user. Moreover, 
they do not teach or suggest summarizing the effect on performance of actions recommended 
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or taken. Indeed, they do not suggest recording performance information at all. 
Consequently, while they do teach summarizing configuration changes implemented, the 
cited references do not teach or suggest either (a) summarizing recommended actions, or 
(b) summarizing the resulting change in performance, as required by Claim 5. 

Claim 6 requires: 

providing a report with performance trends on a plurality of 
computer systems where recommended configuration changes 
are not implemented. 

The Examiner contends that Grieve abstract and Fig. 10 disclose this element. 
Applicants respectfully disagree. As described above, the Grieve abstract describes systems 
and methods for identifying configuration changes and informing the user of them. Fig. 10 
shows the change history, also described above, a tool that presents a chronological list of 
configuration changes to the user. Thus, the cited references do not teach or even suggest 
analyzing performance trends. Indeed, they do not even suggest recording performance 
information. Moreover, they do not suggest distinguishing systems where recommended 
configuration changes were not implemented from those where they were. Thus, the cited 
references do not teach or suggest reporting performance trends on systems where 
recommended changes were not implemented, as required by Claim 6. 

Claim 7 requires: 

analyzing computer metrics on the computer system and 
proposing configuration changes based on the analysis of 
computer metrics. 

The Examiner contends that Grieve f 0004 and Fig. 1 disclose this element. 
Applicants respectfully disagree. Grieve ^ 0004 refers to the prior art of that invention. It 
explains that prior systems usually provided the operator with complete information about the 
complete configuration of the system. Grieve Fig. 1 is a functional block diagram of an 
embodiment of the Grieve invention. It comprises a user interface, a database manager, a 
scheduler, an agent, a file-transfer mechanism, and a plurality of devices in a network. It 
comprises no component that analyzes computer metrics. Also, while the user interface 
displays a history of past configuration changes (see the description above of the change 
history), no component is described that proposes future changes based on an analysis of 
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computer metrics. Thus, the cited references do not teach or suggest analyzing computer 
metrics on the computer system and proposing configuration changes based on that analysis, 
as required by Claim 7. 

Claim 8 requires that: 

obtaining performance metrics for the computer system before 
and after computer configuration changes comprises accessing 
stored computer metrics in a database. 

The Examiner contends that the database manager 108 and Fig. 1 of Grieve disclose 
this feature. Applicants respectfully disagree. As described above, neither the database 
manager nor Fig. 1 of Grieve teach or even suggest obtaining or recording performance 
metrics. The database schema provided by Grieve does not contain a field for storing such 
information. Moreover, as described above, the cited references do not even suggest or teach 
obtaining such performance metrics for a computer system before and after computer 
configuration changes in the first place. 

Accordingly, for at least the foregoing reasons, Grieve does not anticipate Claim 1 or 
Claims 4-8 that depend from Claim 1 . Applicants respectfully request withdrawal of the 
rejection of Claims 1 and 4-8. 

B. Rejections under 35 U.S.C. § 103 

The Examiner rejects Claims 2-3 as being unpatentable over Grieve as applied to 
Claim 1 and further in view of U.S. Patent No. 6,678,639 to Little et al. ( Little ). The 
Examiner also rejects Claims 9-20 as being unpatentable over Grieve in view of Little . For at 
least the reasons that follow, these rejections cannot be properly maintained. 

1. Claims 2 and 3 

Claims 2 and 3 depend from Claim 1, which requires: 

obtaining performance metrics for the computer system before 
and after configuration changes implemented in the computer 
system; and 

assessing effectiveness of the computer configuration changes 
based on the obtained performance metrics. 

As described above, Grieve does not teach or suggest either of these limitations. 
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Little likewise does not teach or suggest either of these limitations. First, Little 
nowhere mentions or suggests obtaining performance metrics for the computer system, before 
and after configuration changes or otherwise. Indeed, where Little presents an exemplary list 
of the elements of the computing environment it considers, it makes no mention of anything 
relating to performance information. Instead, it calls for identifying "administration practices, 
[and] system configuration including hardware, software and the operating system" 
( Little (abstract); Little col. 2, 11. 10-13; Little col. 5, 11 5-7). Thus, Little only suggests 
identifying information about a computer system's configuration, not obtaining performance 
metrics as required by Claims 2 and 3. 

Second, Little does not teach or suggest assessing the effectiveness of computer 
configurations changes based on obtained performance metrics. Little teaches maintaining an 
internal rules database, which is "a compilation of various problems that are known to exist at 
various configurations." Little (abstract); Little col. 2, 11. 14-16. It teaches that each of these 
rules may be associated with a measure of the severity of the corresponding problem (see, 
e.g., Little col. 6, 11. 15-17). However, it nowhere teaches or suggests changing these 
measures of severity based on an analysis of performance. On the contrary, it presents a fixed 
measure of severity for each of a long list of problems its embodiments might tackle. See 
Little col. 6, 1. 35-col. 23, 1. 20. What is more, it organizes this list of problems on the basis 
of this suggested fixed measure (it has successive sections that describe "high" risk problems, 
"medium" risk problems, "low" risk problems, and "critical" risk problems, Id.), which 
further indicates that each suggested measure is intended to be immutable. Thus, Little 
suggests the static process of attaching a fixed measure of severity to each problem in its rules 
database, not the dynamic process of assessing the effectiveness of configuration changes 
based on performance metrics collected, as required by Claims 2 and 3. 

Additionally, Claim 2 requires: 

increasing priority values for computer configuration changes 
resulting in performance improvements, the priority values 
being used for priority of computer configuration changes in 
future recommendation sets. 

The Examiner cites Little abstract and col. 2, 11. 09-42 as suggesting this limitation. 
Applicants respectfully disagree. The cited passages describe maintaining a database of rules, 
but nowhere suggest increasing priority values or measures of severity. In particular, they do 
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not suggest increasing the priority values for configuration changes resulting in performance 
improvements, in part because (as described above), Little does not suggest analyzing 
performance metrics at all. 

Similarly, Claim 3 requires: 

classifying computer configuration changes not resulting in 
performance improvements as secondary recommendations in 
future recommendation sets. 

The Examiner writes that Little Fig. 29 and col. 7, 11. 16-col. 8, 11. 62, teach this 
limitation. Applicants again respectfully disagree. Fig. 29 shows how an embodiment of the 
Little invention deals with a specific configuration problem, viz. the installation of a large 
number of UDWIS/SBus Host Adapters in a computer room. It shows that the number of 
such adapters is checked and, if there are too many, the user is informed. It does not mention 
or suggest reclassifying any rules — the ones dealing with this particular problem or any 
others — as secondary. Similarly, Little col. 7, 11 16-col. 8, 11. 62, describes how an 
embodiment of the Little invention deals with four specific configuration problems. In 
addition to the one described above, these are: the absence of current patches and firmware 
on an A5x00 software patch cluster; the absence of current firmware on drives of type 
ST1 18273FC; and the operation of two different models of or types of disks on a single 
power supply. The cited material describes performing a simple configuration check for each 
of these problems, alerting the user to its existence, and providing simple recommendations to 
fix it. Again, it does not mention or suggest reclassifying any rules as secondary. Thus the 
cited materials do not teach or suggest classifying computer configuration changes as 
secondary and, in particular, do not teach or suggest that this reclassification be driven by an 
analysis of performance metrics, as required by Claim 3. 

A rejection under 35 U.S.C. § 103(a) cannot be properly maintained where the 
references do not teach or suggest each and every limitation of the claim. Grieve in view of 
Little does not teach each and every limitation of Claims 2 and 3. 
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2. Claims 9-16 

Claims 10-16 all depend directly or indirectly from Claim 9, which requires: 

programmed instructions configured to: . . . 

collect performance metrics associated with the computer 
system having the identified implemented configuration 
changes; and 

weight effectiveness of the identified implemented 
configuration changes. 

The Examiner writes that Grieve shows the first of these, and the Little shows the 
second. Applicants respectfully disagree: Grieve does not show the first; Little does not show 
the second. 

In ]f 16 of the Office Action, the Examiner cites to Grieve abstract and 0033, 
01 16-0162 as showing the first limitation above. As described in detail above, these portions 
of Grieve describe collecting configuration information, not performance information. 

In 1f 16 of the Office Action, the Examiner cites to Little (abstract) and Little col. 2, 
11 09-42, as suggesting weighting the effectiveness of the identified implemented 
configuration changes. However, as described above, the cited passages suggest only 
recording a measure of the severity of the corresponding potential problem. They do not 
teach or suggest weighting the effectiveness of the configuration change itself. 

Claim 13 in particular also requires that: 

proposed configuration changes with low weighted 
effectiveness are removed from a recommendation set. 

The Examiner suggests that Grieve 0026, 0045, 0049, 0072, 0080, 0098, 0114, 
and 0151 teach this limitation. Applications respectfully disagree. As described above, the 
cited paragraphs disclose a system that shows the user a history of configuration changes and 
allows the user to interact with it. They do not disclose or even suggest weighting the 
effectiveness of configuration changes. Also, they do not suggest maintaining knowledge 
bases or other recommendation sets to make recommendations about effective configuration 
changes. Thus, they do not suggest removing proposed configuration changes with low 
weighted effectiveness from a recommendation set, as required by Claim 13. 
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A rejection under 35 U.S.G. § 103(a) cannot be properly maintained where the 
references do not teach or suggest each and every limitation of the claim. Grieve in view of 
Little does not teach each and every limitation of Claims 9-16. 

3. Claims 17-20 

Claims 18-20 all depend from Claim 17, which requires: 

means for obtaining performance data for the computer systems 
in the network; . . . 

means for obtaining performance data for the one of the 
computer systemfs] after implementation of recommended 
configuration changes; and 

means for adjusting relative value of the recommended 
configuration changes based on an evaluation of the 
performance data after implementation of recommended 
configuration changes. 

The Examiner has not cited to any part of Grieve or Little that teaches or suggests 
these limitations. Grieve and Little do not teach or suggest these limitations. 

Claim 20 in particular also requires: 

eliminating a configuration change from a recommendation set 
where the configuration change has a low relative value. 

The Examiner suggests that Grieve 1ffl 0026, 0045, 0049, 0072, 0080, 0098, 01 14, 
and 0151 teach this limitation. Applications respectfully disagree. As described above, the 
cited paragraphs disclose a system that shows the user a history of configuration changes and 
allows the user to interact with it. They do not disclose or even suggest computing the 
relative values of different configuration changes. Also, they do not suggest maintaining 
knowledge bases or other recommendation sets which can be updated as these relative values 
change. Thus, they do not suggest eliminating a configuration change from a 
recommendation set where the configuration change has a low relative value, as required by 
Claim 20. 

A rejection under 35 U.S.C. § 103(a) cannot be properly maintained where the 
references do not teach or suggest each and every limitation of the claim. Grieve in view of 
Little does not teach each and every limitation of Claims 17-20. 
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Accordingly, for at least the foregoing reasons, applicants respectfully request 
withdrawal of the rejection of Claims 2, 3, and 9-20. 

Applicant respectfully requests reconsideration of the present application in view of 
the foregoing amendments and the reasons cited above. 

Applicant believes that the present application is now in condition for allowance. 
Favorable reconsideration of the application as amended is respectfully requested. 

The Examiner is invited to contact the undersigned by telephone if it is felt that a 
telephone interview would advance the prosecution of the present application. 

The Commissioner is hereby authorized to charge any additional fees which may be 
required regarding this application under 37 C.F.R. §§ 1.16-1.17, or credit any overpayment, 
to Deposit Account No. 19-0741 . Should no proper payment be enclosed herewith, as by a 
credit card payment being in the wrong amount, post-dated, otherwise improper or informal, 
or even entirely missing, the Commissioner is authorized to charge the unpaid amount to 
Deposit Account No. 19-0741 . If any extension of time is needed for timely acceptance of 
papers submitted herewith, Applicant hereby petitions for such extension under 37 C.F.R. 
§1.136 and authorizes payment of any such extension fees to Deposit Account No. 1 9-074 1 . 



Date September 5, 2007 
FOLEY & LARDNER LLP 
Customer Number: 23524 




Telephone: (608) 258-4292 
Facsimile: (608) 258-4258 



Attorney for Applicant 
Registration No. 44,787 



-14- 



MADI_936486.1 



